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Idolos Virtuales 


Los “personajes 
virtuales” son un tema 
ya añejo en el mundo 
de la ciencia ficción 
del que hay múltiples 
ejemplos: la lA de la 
novela «La luna es 
una cruel amante» de 
Heinlein, el personaje 
“Max Headroom” de la 
serie de televisión, la 
marioneta virtual de 
Johnny Nnemonic... 
Los ejemplos son 
innumerables en el 
campo de la Sci-Fi. 
Ahora bien, ¿existen 
ya personas virtuales 


en el mundo real? 
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que la idea clásica del mismo es la de : 
una representación fotorealista de una ¿ 
criatura virtual residente en uno o varios | 


odo depende de lo a 
que se acepte como E 
definición de “per- ¿ 
sona virtual”. Es di- : 
fícil definir este tér- 
mino. pero parece ¿ 


ordenadores. En otras palabras, una per- 
sona virtual es una Inteligencia Artificial 
(TA) que usa un interface 3d para repre- 
sentarse a s1 misma ante el mundo real. 
Si damos por válida esta definición, 
las personas virtuales no existen aún en 
nuestro mundo real. ¿Existirán algún 
día? Si aceptamos los criterios del fa- 
moso físico-matemático Roger Penro- 


— 


El 17 cumpleaños de Kyoko. 


se, el teorema de Godel demuestra que 
cualquier programa de ordenador está 
sometido a limitaciones básicas que im- 
posibilitan la aparición de la inteligen- 
cia. Otros científicos como John Mc- 
Carthy —creador del lenguaje Lisp- 
opinan que, aún aceptando este punto, 
algún día existirán programas capaces de 
superar el test de Turing —conocido test 
ideado por Alan Turing para determinar 
la posible inteligencia de un programa-—. 
La opinión del autor de estas líneas 
es que McCarthy tiene razón: algún día 
existirán programas inteligentes. De to- 
dos modos es curioso constatar que hoy 
en día ya existen programas no auto- 
conscientes. capaces de conseguir resul 
tados que antes se consideraban sólo re- 
alizables por personas dotadas de gran 
inteligencia. Este es el caso de Deep 
Blue; por su encuentro ajedrecístico con 
Kasparov, o el de los progragnas que han 
desarrollado teorernas matemáticos. Por 
otro lado, en mi Opinión, el test de Tu- 
ring no debería ser aceptado como váli- 
do para medir la inteligencia de un pro- 
grama por dos razones: la primera 
porque creo:que pueden escribirse pro- 
no inteligentes que pasarían el 
test, y la'se porque hay personas 
que probablemente no lo superarían. 
En fin, ya dejando aparte el intere- 
santísimo pero pantanoso campo de la 
inteligencia artificial, hoy día ya exis- 
ten actores, presentadores e, incluso, 
ídolos virtuales. Estas “criaturas” no 
son, por ahora. más que marionetas vir= 
tuales manejadas por sus creadores hu- 
manos. Algunas de ellas interactúan en 


Esta chica no es de carne y hueso. 


tiempo real con el mundo de los seres 
humanos mientras que otras, las más 
“reales”, sólo se emplean en la genera- 
ción de escenas o películas. Veamos al- 
gunos ejemplos. 


DK-96 

DK-96 o Kyoko Date, como se le 
suele llamar, es laprimera estrella vir- 
tual nacida en Japón. Se trata de una 
chica sintética (pero extremadamente 


ista) creada por la agencia japonesa : 


de modelos HoriPro, la cual empleó en 
este proyecto a un grupo de ingenieros 
y diseñadores que durante cerca de año 


y medio trabajaron para dar a luz a a 


Kyoko. El web original de HoriPro es- 
tá en japonés pero, afortunadamente, 
existe una versión traducida al inglés 
de sus páginas. La dirección de este 
web inglés es www.dhv.co.jp 

Los pocos datos que conocemos so- 
bre Kyoko han sido extraídos de diver- 
sos webs dedicados a ella (razón por la 
que pedimos disculpas de antemano, 
por si incurrimos en alguna inexacti- 
tud). Parece ser que su cuerpo virtual 
consta de unos 40.000 polígonos y que 


ha sido elaborado enteramente tisando : 


técnicas de modelado 3d en lugar de, 


por ejemplo, escáneres 3d. En cuanto a j 


la personalidad de Kyoko, sus creado- 
res han sido también muy detallistas: 
Kyokotiene 17 años, grupo sanguineo, 
familia, amigos, aficiones, etc: Ha gra- 
bado varios singles (¡!!), se le han he- 


cho diversas entre- 


vistas, y es una buena danzarina. Salvo 
por el hecho de que no tiene un cuerpo 
físico, a Kyoko no le falta ninguna de las 
características propias de cualquier ídolo 
juvenil. Incluso cienta con varios clubs 
de fans entre los seres humanos reales. 
Naturalmente, y dado que hoy por 
hoy no existe ninguna ÍA digna de este 
nombre, la personalidad de Kyoko ha 
sido creada su 


de varias persons re 


do rasgos diversos 
s. Todos sus 
movimientos y su manera de hailar se 
han tomado de una bailarina real, em- 
pleando “motion capture”, su voz la ha 
tomado “prestada” de una profesional 
de la radio y sus singles han sido gra- 
bados por una cantante japonesa. Sus 
exp “Qnes faciales, movimientos Ocu- 
lares, etc. son (¡ay!) Únicamente mánt- 
pulaciones informáticas a las-que se 
apoya de vez en cuando.con “motion 
capture”. Todo esto, sin embargo, se ol- 
vida rápidamente cuando se.ve una fo- 
to o una animación:de Kyoko, y uno 
acaba viéndola como un ser real, tal y 
como sucede cOn olros personajes de 
ficción particularmente bien esbozados 
por sus creadores: 

Por si aún queda alguien que no lo 
sepa, “motion capture” es una tecnolo- 
gía que permite “capturar” los movi- 
mientos corporales o faciales de los se- 
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res del mundo real empleando sensores o 
cámaras. Estos movimientos se convier- 
ten en datos numéricos 3d que pueden 
ser empleados por modelos en 3D. Se- 
gún parece, en el caso de Kyoko, 
esto ha sido cuidado hasta el pun- 
to de hacer coincidir las expre- 
siones faciales con lo hablado 

o cantado por esta chica. 
El pelo de Kyoko es corto, se- 
gún se afirma para ahorrar 
tiempo de proceso y memoria. 
Las iniciales DK vienen de 
“digital kids” (chicos digita- 
les) y los “padres” de esta chi- 
ca esperan que en pocos años 


la tecnología avance como pa- 

ra permitir que Kyoko participe 

en Shows televisivos de tiempo real, 

junto a los hermanos que, 
sin duda, la seguirán. 

En fin, para aquellos 
que deseéis información 
adicional, os recomenda- 
mos visitar alguna de las 
direcciones indicadas. Po- 
dréis oír cantar a Kyoko, 
verla bailar, leer alguna de 
sus entrevistas (su biogra- 
fía -ay- aún no ha sido tra- 
ducida del japonés origi- 
nal) o enteraros de algunos 
de sus gustos. Como cu- 
riosidad podemos comen- 
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Rina preparándose para salir. 


tar que su película favorita es Toy Story 
y Su tipo favorito de hombre. Goku de 
Bola de Dragón. Casi nada. 


Rina 

Muy poco podemos decir de Rina 
Kawazuki, ya que todas las páginas 
que hemos encontrado sobre ella en In- 
ternet están en Japonés. Tan sólo cons- 
tatar que el estilo 3d con el que está 
creado el cuerpo de esta chica es bas- 
tante más manga y menos realista que 
el de Kyoko. ¿Se tratará de otro ídolo 
sintético quinceañero creado por algu- 
na compañía japonesa? ¿Será la obra 
de algún infografista de talento? En fin, 
mientras esperamos las respuestas po- 
demos, al menos, disfrutar de las fotos. 
Lo cierto es que se parece a Kyoko co- 


¿Es Rina otra modelo 
virtual? 


mo una gota de agua a otra. ¿Será su 
hermanita menor? 


La chica de Tomwoof 

A pesar de su inferior nivel de rea- 
lismo no hemos resistido la tentación 
de incluir aquí a esta chica a la que 
Tomwoof -quizá en serio quizá en bro- 
ma- ha convertido en su candidata al 
estrellato virtual. Encontramos a esta 
chica en una de las páginas de Tomwoof 


¿ junto con una pequeña reseña sobre sus 


gustos, edad y ambiciones: “ser la me- 


S jor estrella virtual posible”. 


Nota del autor 

No hemos encontrado aún ningún 
ídolo virtual masculino, ¿Sera que todos 
los infografistas del planeta son hom- 
bres? Reclamamos la ayu- 
da de las rendermaniacas. 
No hemos incluido aquí 
personajes de videojuegos 
como Chunli, Ryu (Street 
Fighter) o Lara Croft (Tomb 
Raider) porque son conoci- 
dos por los lectores y por- 
que su nivel de realismo es 
menor. Es indiscutible, sin 
embargo, el hecho de que 
estos personajes son, en 
cierto modo, ídolos de po- 
£ — pularidad aún mayor que la 
dela propia Kyoko Date. 
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Trees. inc: 


Un Ipas para crear árboles con POV 


Las fantásticas 
sentencias de 
programación de 
la versión 3 de 
POV están 
propiciando la 
aparición de 
toda una serie 
de “Ipas”, como 
bien podríamos 
llamar a estas 
utilidades, para 


POV. Uno de 


estos “Ipas” es 
Trees.inc de Sonya Roberts. Esta utilidad es quizá el mejor camino para 
crear árboles para nuestras pov-escenas. Con Trees.inc podremos generar 
árboles de apariencia realista o alienígena, y controlar con facilidad su 


forma, tamaño, nivel de complejidad, colorido y muchas otras cosas más. 
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Nnsón 


n el número 6 de 
Rendermanía se in- 
cluyó una pequeña 
disertación sobre el 
funcionamiento y 
uso de las pov-fun- 
ciones de usuario o pov-macros (como 
prefiere llamarlas el autor de estas lí- 
neas). Como entonces vimos, una pov- 
macro es, simplemente, un fichero «inc 
que contiene un conjunto de sentencias 
pov. De cara al usuario, las pov-macros 
funcionan exactamente igual que las 
subrutinas de programación, siendo 
empleadas por lo general para crear ob- 
jetos cuya forma exacta de- 
penderá de los valores que se 
haya dado a las variables de 
la pov-macro. Como recorda- 
rá el lector, el truco consistía 
en dar unos valores determi- 
nados a las variables de la 
pov-macro, en el fichero pov, 
y luego usar una sentencia in- 
clude para “incluir” las sen- 
tencias de la pov-macro. Este 
proceso puede repetirse cuan- 
tas veces se desee obteniendo resulta- 
dos diferentes en función de los valores 
que se hayan dado a la pov-macro. 
Mencionamos todo esto porque la 
utilidad Trees.inc de Sonya Roberts 
es una pov-Macro. Así, para cada ár- 
bol que deseemos crear, habrá que 
indicar los valores correspondientes 
para las variables y colocar una sen- 
tencia include. 


Notas sobre los manuales 

A partir de la versión 2.0 de Trees, 
Sonya decidió escribir un tutorial en 
formato html (y en inglés) para su utili- 
dad. Algún tiempo después, un usuario 
realizó una excelente traducción al cas- 
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tellano (también en formato html) que 
hemos incluido en el CD. Dicha tra- 
ducción, no obstante, está algo anticua- 
da, ya que se refiere a la versión 2.0 de 
Trees. La nueva versión de trees, la 3.0, 


incluye un fichero html adicional y pre- 
senta cambios en el apartado “Hojas, 
flores y frutos” con respecto al antiguo 
tutorial. Todo lo demás —la explicacio- 
nes acerca de cómo se generan los ár- 
boles y el funcionamiento de las varia- 
bles— es prácticamente idéntico en 
ambos tutoriales. Este artículo se ha es- 
crito gracias a la información suminis- 
trada por estos ficheros, la cual ha sido 
contrastada (claro está) con nuestras 
propias pruebas. 


Los arboles de Sonya 
Los árboles generados con el “Ipas” 
escrito por Sonya Roberts son —como 
ocurre con los creados por otras utili- 
dades semejantes— modelos formados 
por cientos o miles de objetos simples. 
Estos objetos simples son. en su mayor 
parte, conos y esferas. Los conos se 
usan para formar el tronco y las ramas, 
y las esferas se emplean para suavizar 
las uniones entre los conos. Puede pa- 
recer increíble que los árboles que aquí 
veis se obtengan partiendo de formas 
tan simples pero el caso es que es así. 
Los que os animéis a examinar el fi- 
chero Trees.inc observaréis que Sonya 
ha hecho un experto uso de las llama- 
das sentencias de programación de 
POV (if, while, switch, case, rand y 
otras). Estas sentencias han sido em- 
pleadas para escribir los 5 bucles ani- 
dados que sirven para generar los 5 ni- 
veles de estructura con que cuentan 
todos los árboles que se construyen con 


trees.inc. Estas estructuras son el tron- 
co, las ramas primarias (las que parten 
del tronco), las secundarias, las tercia- 
rias y las terminales, a las que aquí Ha- 
maremos ramitas. En cuanto a las posi- 
bles hojas. flores y frutos del árbol, sólo 
pueden partir de las ramitas de éste y el 
número y distribución de las mismas de- 
penderá, tal y como sucede con el resto 
de las estructuras del árbol, de los valo- 
res que demos a una serie de variables. 


La pseudoaleatoriedad es 
necesaria 

La forma y aspecto finales de cada 
árbol dependen de una serie de varla- 
bles que Sonya clasifica en tres catego- 
rías: las variables para los generadores 
de números aleatorios, las variables 
que controlan la forma y distribución 
de las estructuras del árbol, y las varia- 
bles que afectan al tamaño y las pro- 
porciones del árbol. 

Las variables de la primera catego- 
ría sirven, como ya imaginará el lector, 
para obtener árboles diferentes. Aquí 
sentimos la necesidad de hacer un in- 
ciso en beneficio de aquellos render- 
maniacos que desconozcan lo que es 
un generador de números pseudoalea- 
torios. Los lenguajes de programación 
suelen implementar sentencias que re- 
tornan números que parecen tomados 
al azar. Realmente la rutina que consti- 
tuye el generador emplea una fórmula 
para generar los números devueltos, 
con lo cual no puede decirse que estos 
sean aleatorios. Pero, sin embargo. a un 
ser humano le resultará imposible pre- 
decir a priori los valores que devolverá 
el generador. Por otro lado el genera- 
dor necesitará un valor llamado semilla 
como entrada para ser inicializado. 
Después de dicha inicialización, y cada 


vez que sea invocado, el generador nos 
devolverá el siguiente valor “aleatorio” 
que corresponda a la semilla suminis- 
trada; por esto se llama pseudoaleato- 
rios a estos números. Lo más importan- 
te es, como veremos enseguida, que 
una semilla dada produce siempre la 
misma secuencia de valores. ¿Para qué 
puede sernos útil esto? Bien. en info- 
grafía existen bastantes aplicaciones en 
las que es imprescindible el uso de nú- 
meros pseudoaletorios. En el caso de 
trees, por ejemplo, los valores devuel- 
tos por la semilla SD] se usan para 
controlar el núme- 
ro de ramas y la 
orientación de las 
mismas. Esto sig- 
nifica que bastará 
con cambiar el va- 
lor dado como se- 
milla en la variable 
SD! para obtener 
un árbol diferente. 
(Y también signi- 
fica que no podre- 
mos predecir si la 
construcción del 
árbol nos parecerá 
satisfactoria. Si no 
lo es tendremos, 
simplemente. que probar con otros va- 
lores diferentes para a semilla). 

En cuanto a la obtención de la mis- 
ma serie de valores en cada uso de una 
misma semilla, se trata de algo cuyas 
ventajas resultan obvias. Por supuesto, 
no hay ninguna razón para tener dos ár- 
boles idénticos en un bosquecillo pero, 
si estamos creando una animación. esta 
característica resultará indispensable 
para no obtener un árbol distinto en ca- 
da frame de la misma. Como recorda- 
réis el generador de POV permite em- 


plear varias semillas al mismo tiempo. 
Dependiendo de cual sea la referencia- 
da (por la sentencia rand). el generador 
nos devolverá un valor u otro. Gracias a 
esto Sonya ha podido emplear tres se- 
millas en Trees: además de SD1, que 
controla las divisiones de ramas en el 
árbol, trees usa las variables SD2 y 
SD3. SD2 nos permitirá cambiar la dis- 
tribución aleatoria de las hojas, flores 
y frutos en las ramitas sin alterar la dis- 
tribución general de las ramas ni el nú- 
mero de las mismas (o sea, lo controla- 
do por SD1). SD3 se emplea en 


algunas cuestiones aleatorias relacio- 


nadas con las hojas, flores y frutos. 


Variables que afectan a la 
distribución y a la forma 
Aparte de las semillas SD1 y SD2 
existe una serie de variables que nos 
permitirán un control más “predecible” 
sobre la forma global del árbol. Se trata 
de las variables que controlan los án- 
gulos de división. Este nombre alude a 
los ángulos que se formarán en cada eje 
entre una rama dada y el tronco. Para 


comprender esto hay que saber cómo 
crea trees las ramas. Inicialmente cada 
rama es creada con la base en el origen 
y extendiéndose paralela en el eje Y. 
Seguidamente se rota en el eje X una 
cantidad aleatoria de grados, pero di- 
cha cantidad se mantiene comprendida 
entre los valores dados a MinXDeg y 
MaxXDeg. Podemos dar a estas varia- 
bles el valor que deseemos pero parece 
que lo mejor es dar 10 a MinXDeg y 
poner 30 ó 40 en MaxXDeg. 

Después de esta rotación en el eje X, 
otra rotación aleatoria en el eje Y dará 
a la rama la orientación adecuada con 
respecto a la rama padre. De nuevo los 
valores aleatorios devueltos estarán 
comprendidos por los números dados a 
dos variables: MinYDeg y MaxYDeg. 
Si se desea un reparto uniforme de ra- 
mas alrededor del árbol, lo cual es lo 
normal, los valores respectivos para es- 
tas variables deberán ser O y 360. Valo- 
res diferentes ocasionarán que las ra- 
mas sean creadas sólo en una sección 
del tronco (lo cual puede ser útil si que- 
remos simular un efecto de viento en el 
árbol). Las variables MinZDeg y 
MaxZDeg realizan la misma función 
en el eje Z pero normalmente no son 
necesarias y podemos dejarlas a O, 

Las tres variables siguientes se em- 
plean para conseguir un interesante 
efecto: lograr que las ramas se vayan 
curvando hacia abajo más y más, a me- 
dida que se alejan del tronco. Para con- 
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seguir esto, los valores dados a las va- 
riables IncXDeg, IncYDeg y IncZDeg 
se suman a los valores mínimos y má- 
ximos de las variables explicadas ante- 
riormente. Si por ejemplo hemos dado 
el valor 5 a IncXDeg, y teníamos los 
valores 30 y 40 en MinXDeg y MaxX- 
Deg, los valores aleatorios devueltos en 
el eje X estarán comprendidos entre 30 
y 40 grados para las ramas primarias 
pero pasarán a oscilar entre 35 y 45 
grados para las ramas secundarias y las 
ramas terciarias se inclinarán entre 40 y 
50 grados. Podemos dar valores negati- 
vos a IncXDeg con lo cual las ramas se 
curvarán hacia arriba. 

Las siguientes variables de este gru- 
po afectan a la frondosidad del árbol. 
Los valores dados a MinSplits y MaxS- 
plits servirán para especificar el núme- 
ro mínimo y máximo de ramas que 
pueden partir del tronco o de una rama 
padre. Hay que tener cuidado sobre to- 
do con el valor dado a MaxSplits, ya 
que el número de objetos del árbol po- 
dría dispararse. Como nuevamente se 
usa el generador de pseudoaleatoriedad 
nos será imposible predecir el número 
total de ramas (a menos que los valo- 
res para ambas variables sean idénti- 


cos) pero si podemos saber el número 
máximo de objetos que tendrá el árbol. 
Sonya adjunta el siguiente ejemplo. Pa- 
ra un valor de 4 en MaxSplits, el núme- 
ro máximo de ramitas será de 


4+4*4*4-256 


(Sólo hay 4 multiplicaciones porque 
aunque hay 5 niveles de estructuras-ra- 
ma, el primer nivel es el tronco). 

Otra variable importante es Inc- 
Splits. Al usar Trees, el usuario tenderá 
a dar valores relativamente altos a 
MinSplits y MaxSplits para obtener ár- 
boles frondosos. El resultado final, no 
obstante, puede ser insatisfactorio si lo 
que buscamos es conseguir una distri- 
bución más “real”. Como hace notar 
Sonya, los árboles reales tienen por lo 
general más ramas secundarias en Ca- 
da rama primaria que primarias en el 
tronco y más ramas terciarias en cada 
secundaria que secundarias en cada pri- 
maria. O sea, que la complejidad es- 
tructural de los árboles suele ir crecien- 
do en cada nivel a medida que nos 
alejamos del tronco. Sonya implemen- 
ta la variable IncSplits para simular es- 
to. IncSplits es un multiplicador que 


afecta a MaxSplits en cada nivel de la 
estructura. Supóngase que tenemos un 
valor MaxSplits de 4 y un valor de 
IncSplits de 1.25 (ejemplo dado por 
Sonya). Entonces el máximo número 
posible de ramas primarias será de 4 
pero el de ramas secundarias podrá ser 
de 5 y el de ramas terciarias de 7. Aquí 
Sonya hace dos recomendaciones: 
¡Cuidado con el máximo número posi- 
ble de ramas! También es recomenda- 
ble emplear las variables de incremento 
de grados, ya de lo contrario podría 
ocurrir que todas las ramas se apeloto- 
narán en un mismo volumen espacial. 


Tamaño y proporciones 

No es nada recomendable realizar 
operaciones de escalación una vez cons- 
truido el árbol ¡tiene demasiados obje- 
tos! En lugar de esto daremos el valor 
adecuado a la variable BaseLen, que se 
emplea para determinar el tamaño del 
árbol. BaseLen —cuyo valor por defecto 
es 1- es el radio de la base del tronco 


del árbol. Como, 
por defecto, el ár- 
bol tiene siempre 
las mismas propor- 
ciones, cambiando 
esta variable cambiaremos el tamaño 
global del árbol. (El tronco del árbol tie- 
ne una altura de unos 19 metros). 

Otra variable importante es Lenght- 
Inc que se usa como multiplicador para 
modificar las proporciones del árbol. 
Un valor de 1 da como resultado árbo- 
les compactos y un valor cercano a 2 
nos da árboles “estirados”. 

Por último BallJoint controla el ni- 
vel de detalle (o número de esferas de 
suavizado) del árbol. Con un valor de O 
las esferas se desactivan (ahorrando 
tiempo y memoria) y con un valor de 5 
se obtiene el máximo nivel de detalle 
(para cámaras muy cercanas al árbol) 


Hojas flores y frutos 
Los cambios más importantes que 
trae la versión 3.0 de Trees con respec- 
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to a su predecesora están en este apar- 
tado. Ahora el usuario podrá elegir en- 
tre una librería bastante amplia de ob- 
jetos para adornar sus árboles con 
hojas, frutos y ramas. E incluso podrá, 
si es preciso, incluir sus propios objetos 
para que sean usados con este fin por 
la utilidad. 

Los objetos de la librería son en su 
mayor parte muy sencillos (la naranja 
es una esfera simple, el limón es una 
triple esfera algo alargada, etc.). Esto 
se debe, por supuesto, a que los árboles 
se construyen a base de cientos e inclu- 
so miles de objetos. Si estos objetos no 
fueran lo más sencillos posible, enton- 
ces el tiempo de render se dispararía 
(ejem, en realidad ya se dispara). Esto 
hace que la opción de incluir objetos 
propios en el árbol no sea demasiado 
útil. En teoría sería fantástico crear un 
árbol que tuviese mangababes, coches u 
otros objetos complejos como frutos. En 
la práctica, no obstante, el tiempo y las 
limitaciones de ram lo hacen imposible. 

Ahora veamos las variables que in- 
dican a Trees qué objetos deben usarse 
como hojas, frutos y ramas en el árbol, 
y cuál ha de ser su apariencia. En pri- 
mer lugar tenemos a LeafShape cuyo 
valor designará al objeto de la librería 
que hará las veces de hoja. Su valor 
puede ir desde O a 8. En cuanto a la tex- 
tura que se aplicará a la hoja seleccio- 
nada, será la indicada por el valor que 
demos a LeafTexture. Después tene- 
mos a FruitShape, que será usado de la 
misma manera para indicar al objeto de 
la librería que servirá como fruto. El 
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valor de esta variable puede estar com- ¿ 
prendido entre O y 5 y el número de la a 
textura para el fruto se especificará en E 
FruitTexture. Finalmente el valor de E 
FlowerShape se emplea para indicar a E 
Trees el tipo de flor que queremos para a 
el árbol y el valor de FlowerTexture se E 


usa para indicar la textura correspon- 


diente. Hay 6 posibles flores y 6 texturas E 


posibles entre las que podremos elegir. . 

En todos los,casos.el valor por de- ¡ 
fecto asignado a estas variables es O y a 
el valorusado para indicar que va a em- E 
plearse un objeto o una textura creada : 


por el usuario es de 1. En este último 
Caso el usuario tendrá que declarar el : 
objeto con el nombre que se indique : 
entre paréntesis en “user-defined” en el : 
fichero tutorial.htm, en el apartado co- ¿ 
rrespondiente. (Nota: no vamos a dar ¿ 
ahora una relación acerca de las formas E 
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y texturas de la librería que correspon- 
den a cada valor, ya que Sonya ha in- 
cluido unas escenas para ilustrar esto 
en el fichero ya mencionado). 
Seguidamente hay una serie de va- 
riables que controlan el número de ho- 
jas en cada ramita (con LeafNum) y la 
orientación de las mismas (con Leaf- 
Rosette). Dicha orientación forma, por 
defecto, una espiral a lo 
largo de la ramita (sula- 
mente las ramitas pueden 
tener hojas, flores y fru- 
tos). Poniendo “True” en 
la variable LeafRandRot 
lograremos una distribu- 
ción más irregular y alea- 
toria (cambiando el va- 
lor-semilla de SD2). Por 
último podemos lograr 
un bonito efecto de rose- 
ta en las hojas poniendo 
“true” en LeafRosette. 
También habremos de 
especificar qué tipo de 
objeto deseamos que ten- 
ga el árbol al final de ca- 
da ramita. Esto se con- 
trola con el valor de Tip. 
Los posibles valores 
asignables a esta variable 
-por defecto el valor es 1- 
son O (nada), 1 (hoja). 2 (fruto) y 3 


(flor). Con respecto a esto puede, suce- 


der que nos parezca un poco irreal que 
todas las ramitas tengan un objeto en 
su extremo (aunque sería prácticamen- 
te imposible asegurarlo en un árbol me- 
dianamente frondoso). 

Para indicar a Trees el porcentaje de 
ramitas que tendrán Un objetu en su ex- 
tremo usaremos la variable TipPercent, 
dándole un valor oscilante entre O y L. 
Además podemos emplear la variable 


Perera ree re rre raro oo ccrncocrcoranionoos 


EAEAA 
FAA EA 


TipOther de manera conjunta con la 
anterior si deseamos que Trees elija 
entre dos objetos a colocar al final de 
la ramita. Para ello indicaremos en Ti- 
pOther el número del segundo objeto 
y TipPercent indicará el porcentaje de 
empleo de uno u otro objeto para las 
ramitas. 

Se nos olvidaba indicar que también 
hay que indicar el número de textura 
para la corteza del árbol en la variable 
BarkTexture. La librería dispone de 6 
texturas de corteza (0 a 6) y el valor 
usado por defecto es el O. 


Texturas propias 

Aunque la posibilidad de crear ho- 
Jas, frutos.o flores de formas nuevas no 
llegue quizáa ser demasiado utilizada 
por el usuario, si parece muy útil poder 
definir texturas propias para cualquier 
objeto del árbol. Esto puede hacerse de 
dos maneras. La más evidente es asig- 
nar la textura definida a. por ejemplo, 
el tipo de hoja que vaya a utilizarse, pe- 
ro esto presenta un inconveniente: ;to- 


A A 


das las hojas del árbol serán exacta- 
mente iguales! No es que esto sea ne- 
cesariamente malo, sobre todo si el ár- 
bol va a estar a cierta distancia, pero 
podemos lograr un interesante efecto 
empleando otro método. 

Definiremos nuestra propia hoja para 
el árbol sin asignarle ninguna textura y 
luego, después del Hinclude “trees.inc”, 
pondremos la textura para las hojas 
dentro de la declaración del objeto-ár- 
bol. Como ya saben los pov-maniacos, 
de esta manera la textura se aplicará so- 
bre todos aquellos objetos que no ten- 
gan declarada su textura propia, o sea, 
en nuestro caso, sobre las hojas. Natu- 
ralmente si la textura del ejemplo es un 
pigmento simple no habrá ninguna di- 
ferencia con respecto al primer méto- 
do, pero si se está empleando un mapa 
de color los resultados serán similares a 
los que pueden verse en el ejemplo del 
árbol vtoñal de la foto con el lancero 
medieval. Este ejemplo lo encontraréis 
en lancer.pov y lancerl.pov. 


Usando los arboles de Sonya 

En una de las pruebas realizadas, el 
autor de estas líneas decidió crear un 
árbol cuyas proporciones fuesen con- 
gruentes con las del lancero medieval 
que se creó para estas páginas hace ya 
tanto tiempo. Como antes se ha dicho, 
la altura por defecto del árbol es de 
unas 19 unidades, que aquí aceptare- 
mos como metros. Por tanto para obte- 
ner una altura de unos 9 metros bastará 
con dar un valor de 0.5 a BaseLen. En 
cuanto al lancero, tenía unas 15 unida- 
des de alto, ya que en las escenas para 
las que fue originalmente exportado ca- 
da metro equivalía a 10 unidades. Por 
esta razón el modelo fue escalado por 
0.10 en todos los ejes. 


Por lo que respecta al 
árbol, se empleó un ma- 
pa de color para lograr 
la diversidad de color 
deseada entre las hojas 
—aquí se usó el truco 
descrito en el apartado 
anterior—. La escena se 
renderizó a baja resolu- 
ción pero luego, al lan- 
zarla al tamaño final, se 
advirtieron algunos efectos indeseables. 
En primer lugar, aunque las proporcio- 
nes generales del árbol eran correctas 
con respecto al lancero, no ocurría lo 
mismo con los frutos —limones—. los 
cuales por su tamaño mas bien parecían 
melones. Además, el número de limo- 
nes era excesivo. Por ello, en una segun- 
da prueba, se empleó la variable TipPer- 
cent con un valor de .40. Además se 
copió la definición del limón de Sonya 


para crear un fruto de usuario, pero es- 
calándolo por 0.50 para que las propor- 
ciones fuesen correctas. De todos mo- 
dos, a pesar de esto, los limones fueron 
sustituidos por flores en la escena final. 
¡Sencillamente ya había demasiados to- 
nos anaranjados en la escena! 

Aparte de esto, se uso InsSplits con 
1.25 para conseguir el efecto de distri- 
bución “natural” de ramas comentado 
por Sonya y se dio un valor de 8 a 
IncXDeg para que las ramas se fueran 
curvando progresivamente. El valor 
que se ha dejado en SDI es el que ge- 
neró el árbol más potable estéticamen- 
te hablando. 


Algunos consejos 

1) Realizad las pruebas iniciales de 
color, tamaño y proporciones del árbol 
con valores bajos para MinSplits y 
MaxSplits. Ahorraréis tiempo. 

2) Si queréis recuperar los valores 
por defecto de Trees para crear un nue- 
vo árbol, incluid el fichero defaults.inc 
que adjunta Sonya. 

3) No escaléis el árbol, usad Base- 
Len. No rotéis los árboles, dispararéis 
el tiempo de cálculo. 

4) No coloquéis varios árboles de- 
masiado cerca unos de otros. Si sus vo- 
lúmenes se entrecruzan el tiempo de 
cálculo se disparará igualmente. 
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Crear terrenos para 


A menudo es conveniente rematar una escena insertando en 


ella un buen paisaje de ¿En Esto puede ser bastante 


problemático ya que, aunque existen muchas utilidades que 


generan “heightfields” para todo tipo de programas de render, 


no son tantas las que nos permiten tener algún control sobre la 


apariencia final del paisaje deseado. Este problema también se 


presenta con nuestro querido POV pero, al menos, podemos 


elegir entre bastantes herramientas de generación de paisajes 


para ayudarnos en este asunto. De entre todas eilas quizá sea 


Héklab de John P. Beale fa más potente y fácil de usar. 


ntes de entrar en las E 
particularidades de é 
H£lab nos sentimos ¿ 
obligados a hacer . 
un inciso para ex- : 
plicar algunos con- : 
ceptos básicos en beneficio de los pov- , 
adeptos más novatos. Los povmaniacos E 
más veteranos pueden saltarse tranqui- a 


lamente el siguiente apartado. 


Los campos de alturas de POV : 
El lenguaje escénico de Pov dispone ¿ 
de una sentencia llamada height field E 


que permite al usuario generar paisajes : 
montañosos. Esta sentencia crea un ob- E 
jeto compuesto por una malla de vérti- E 
ces cuyas “alturas” son determinadas y 
por los valores de color de los pixels de ' 
un bitmap que el usuario selecciona pa- E 
ra tal propósito (y que se suministra co- q 
mo entrada para la sentencia). Natural- . 
mente el fichero con el bitmap no será z 
“pintado” a mano por el usuario (con E 
el auxilio de algún programa de dibujo E 
2d), sino que será generado por el mis- E 
mo POV o por alguna utilidad de la que E 


eche mano el pov-adepto. 


Otra posibilidad. de la que no vamos 
a ocuparnos hoy, consiste en importar 
un objeto con el paisaje ya creado por 
alguna utilidad. En este caso bastaría 
con “traducir” el objeto al formato de 
POV -si ello es necesario— y escalarlo 
y situarlo debidamente. 

El número de vértices que tendrá el 
objeto que resultará del Height_fic d 
dependerá de la resolución del bitmap 
empleado, ya que cada pixel genera un 
vértice. Esto no afectará, no obstante, 
a las dimensiones del objeto, que ten- 
drá 1 unidad de largo en los ejes X y Z. 


escenarios de POV 


El siguiente 
: parámetro afecta 
¿ala “apal ia 
el height_ fiel 
Como ya hemos - 
dicho, Éste está 
compuesto por. 


bitmap 


-osiblesar" > 
a ande 


WE Y final del 


ys de 16 bits son los más r 
lados para nuestros proposa > ES se dla 
que nos permitirán obtener una grada- i tada. ES 


ción de alturas más suave (o sea, 65536 3 embargo. 2 
alturas dentro de un rango de O a 1). a algo — peo o App lc acición le, Eo: 
El formato de esta sentencia €s: : deseable en un 
height_field ( : paisaje montañoso h > 
Tipo_de_fichero “nombre_fichero” : mente incluiremos esta p 
[ nivel_del_agua | E modifica las normales p Car 
[smooth |] . objeto. a fin de cons 14 =: ora la escena. 
[ hierarchy ] : riencia más “suavizada”. 
) : En cuanto a “hierar a 


El formato del fichero empleado pa- , cuya función pa 


ra el bitmap puede ser gif, tga, pot, png, los tests Et 
pgm o ppm. (El formato gif sólo per- : A bi . 
A - de $ 
mitirá 256 alturas porque su paleta es a  vezcrcado,el objeto hei igh field 
le 8 bi á E queda dispuesto de tal modo que su 


n truco que ya h 


] agua € esun : esquina inferior izquierda sitúaen i oca 
r flota r com- > ap posición <0,0,0> y su esquina su- d senta, , COMO | 

dido 5 2d se refiere: perior derecha queda en <l, ,1,1>. Por E problema rd la forma final del 
precisamente a eso: a la altura a la que E Sy sj y heightfield es poco previsible. Pero, 
supuestamente se halla el nivel del : pe i afortunadamente, Hf-lab —la utilidad 
a en el objeto hcight field. Los ¿ ¿que adjuntamos en el CD- podrá ayu- 
triángulos cuyos vértices tengan al altu- darnos en esto. 
inferiores a la indicada ent este e pará- H£-lab es una utilidad que puede ge- 
no serán visibles; Pov los i igno- nerar, manipular y visualizar height- 
fields. Se trata, de hecho, de un conjunto 
de utilidades que han sido agrupadas por 
Beale. (Entre ellas esta Gforge, creada 


tos otros métodos, el 


rará. Por ejemplo, un valor de .5 en este , 
campo le dice a POV que ignore la mi- 
tad inferior del objeto. 


Efecto Ring. 
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La filosofía de 
trabajo de Hf-lab 
Gran parte de la filoso- 
fía de HfFlab se basa en 
la idea de la pila o stack. 
Una idea con la que es- 
tarán muy familiariza- 


porel propio Beale, y que 
quizá sea conocida por al- 
gunos pov-maniacos). El 
funcionamiento de Hab 
se asemeja en gran medi- 
da al de un sistema opera- 
tivo de factura antigua co- 
mo CP/M o MS-Dos 
puesto que trabaja me- 


dos los programadores 
de Ensamblador y los de 


diante comandos escritos. Forth. Para explicar có- 


Creación de cráteres. 


Estos comandos pue- mo funciona se suele re- 


den ser clasificados en 


currir a la imagen de la 


varias categorías dife- ; : típica pila de platos del 
rentes. Por un lado tenemos los coman- S cuentra en c:ipov30]Moolsihf-lab debe- ; fregadero: el primer plato que se colo- 
dos de generación del heightfield, lue- E remos escribir E có en la pila está ahora en el fondo de 
go están los operadores y los comandos , SET HFLHELP=<c:/pov301/tools/ a la misma y el último ha quedado en la 
de manipulación, hay un comando para a hf-lab/hflab.hlp E cima y será, por consiguiente, el pri- 
la visualización del bitmap que corres- . E mero en ser fregado. Lo mismo sucede 
ponde al heightfield en curso y otros a Una vez dentro del programa podre- , con la pila de Hf-lab la cual tiene, ini- 
para visualizar y manipular al objeto 3d : mos acceder a esta ayuda en línea te- E cialmente. un límite de 4 heightfields, 
resultante, tenemos también órdenes : cleando help o “?” para ver una lista de A El sistema de trabajo habitual consiste 
para manipular el stack y otras de cla- : las Órdenes permitidas por la utilidad o ¿ en generar uno o más heightfields con 
sificación menos clara. a usando “help comando” para obtener : la orden Gforge y realizar diversas ma- 

: información específica de una orden u a nipulaciones en ellos (como añadirles 
Instalando Hf-lab ; operador determinado. E cráteres) para después visualizar los re- 


Debemos descomprimir el fichero zip : 
con la orden “Pkunzip -d hf-lab.zip”. la . 
cual creará un subdirectorio llamado E 
hf-lab, dentro del cual se descomprimi- ; 
rá la utilidad. Aparte de algunos fiche- E 
ros de texto y del propio programa ve- 
remos un fichero llamado hf-lab.hlp 
que es la ayuda en línea del programa. : 
Es conveniente instalar dicha ayuda ¿ 
puesto que en ella se explican todos los E 
comandos aceptados por Hflab (y que : 
no se explican en los otros ficheros de . 
texto). Para instalar dicha ayuda edita- : 
remos nuestro fichero autoexec.bat y 


o 
colocaremos una línea de la forma: 


q. 
-. 
- 
. 


SET HFLHELP=path_a_hf-lab.hlp 
Aumentando el número de cráteres. 
es decir, que si el programa se en- 
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Usamos floor con un valor de 0.10. 


sultados con View. Pasaremos de uno a 
otro heightfield manipulando la pila y 
por último, cuando el resultado de 
nuestro trabajo sea satisfactorio, podre- 
mos grabar el bitmap resultante, que 
luego podrá ser empleado desde POV 
en alguna sentencia height_field. 


El comando gforge 

El comando de generación más im- 
portante es Gforge y su formato es: 

Gforge <n-puntos> <aspereza> 

Esta orden crea una malla (o array) 
cuadrada de n-pixels por lado. La apa- 
riencia de la superficie es controlada por 
el parámetro “aspereza” cuyo valor por 
defecto es de 2.1; un valor que da una 
apariencia fragmentada. Si reducimos es- 
te valor, la apariencia será algo más suave. 

Hay que tener cuidado con el tamaño 
de los arrays ya que el gasto de memo- 
ria va incrementándose a medida que 
crece la dimensión del array. Podemos 
realizar pruebas válidas cun un tamaño 
de 256 puntos y luego emplear valores 
de 512 puntos o incluso más. 

Nota: Debido a la forma en que se ha- 
cen los cálculos, HFlab necesita 8 bytes 
por pixel durante el proceso de genera- 
ción. ¡Esto significa que generar una 


malla de 1000*1000 vértices requerirá E 


8 megabytes! Por otro lado parece ser 
que hay un bug perdido en la programa- 
ción de H£lab, Dicho bug produce una 


fragmentación de memoria Ram similar : 


a la que sucede con el tiempo en los dis- 
cos duros. Así, a medida que aumenta 


el número de operaciones realizadas, el E 
programa irá desperdiciando más y más E 
memoria hasta que aparezca el temido ¿ 
mensaje de “out of memory”. La única a 
solución que hay para esto es, por aho- E 


ra, Salir del programa y volver a entrar. 


Cada vez que creamos un height- : 
field, la nueva malla pasará a quedar en , 
la cima de la pila, donde podrá ser mani- E 
pulada y visualizada usando los coman- : 
dos oportunos —los heightfields anterio- a 
res serán desplazados hacia abajo en la a 
pila—. Los comandos “de trabajo” afec- ¿ 
tan siempre al elemento que se halle en la : 
cima del stack con lo cual, para trabajar E 
sobre otro heightfield, tendremos primero : 
que colocarlo en la cima de la pila, lo que E 
llevaremos a cabo empleando alguna de - 
las sentencias de manipulación de la pila : 
(como “rot”, que hace rotar los elementos E 
de la pila, o como “swap” que intercam- : 


bia el primer y el segundo elemento). 


Otro dato a recordar es que cada vez . 
que se imparte una orden gforge, la ma- : 
lla que se producirá será diferente pues- a 
to que el programa emplea un genera- E 
dor de números pseudoaleatorios con z 
este fin. Sin embargo podremos generar : 
de nuevo una malla anterior que nos ha- a 
ya gustado si reseteamos el generador E 
suministrándole la misma semilla que . 
dimos para la anterior. Podemos hacer E 


esto escribiendo... 
seed valor_de_semilla 


En la práctica es conveniente escribir ¿ 
un valor de semilla antes de cada orden ¿ 
gforge, por si se produce un error o 


Añadimos un Ceil de 0.70. 


queremos recrear parcialmente el desa- 
rrollo de un experimento. 


Una sesión de trabajo típica 
Ahora comencemos la sesión de tra- 
bajo. Empezaremos por crear dos height- 
fields de distintas resoluciones: el prime- 
ro con 128 pixels y el segundo con 256 
(gforge 128 y gforge 256). Ahora escri- 
bid “list”. Esta última orden listará en 
pantalla los datos de los heightfields 
guardados en el stack. La primera línea 
de datos corresponde a la cima de la pila 
que, como veréis, está ocupada por el úl- 
timo heightfield creado (el de 256 pi- 
xels). Seguidamente teclead “view” para 
generar una vista tridimensional de este 
heightfield. El programa dispone de di- 
versas calidades de visualización pero te- 
niendo en cuenta el poco tiempo que 
precisa el render con la calidad máxima, 
vale la pena dejar activada esta última. 
Una vez en el modo “view” podremos 
impartir diversas Órdenes particulares 
para este modo. Para ello esperaremos a 
que el render concluya y entonces tecle- 
aremos la orden y su parámetro (si lo 
hay) seguida de return. Así, para regre- 
sar al modo normal de texto, tecleare- 
mos “quit” seguido de return. Otras ór- 
denes válidas desde el modo “view” son 
“S modo _de_ sombreado” (con valores 
de 0a 3), “G modo_grafico” (que admi- 
te 0=320*200. 1=640*480, 2=800*600 
y 3=1024*768), y “Tn”. Esta última or- 
den parece generar un “tileado” a partir 
de la malla inicial, o al menos eso es lo 
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Zedge permite alisar los bordes. 


que se aprecia desde el modo 3d 
(tl =activar el tile, tO=desactivarlo). En 
el modo de visualización 2d, sin em- 
bargo, (orden show) veremos que el 
bitmap no ha cambiado en nada (¿?). 
Ahora vamos a hacer algunos expe- 
rimentos con la malla pero antes será 
conveniente preservarla ya que Hf-lab 
no dispone de undo. Regresad al modo 
2d y pulsad “dup”. Después ordenad un 
listado (“list”). Como veréis ha apare- 
cido una nueva malla de idénticas ca- 
racterísticas a la de la cima. 
Ahora realizaremos algunos 
experimentos. Primero pulsad 
* 2”. Esta operación multi- 
plica por 2 la altura de todos 
los puntos de la malla. Hf-lab 
nos permite emplear varios 
operadores como +, -, *, / y 
Pow, cuyo uso afectará a ca- 
da vértice del array. Si el re- 
sultado de la operación no 
nos ha convencido demasia- 
do podremos hacer que el 
heightfield vuelva a su estado 
anterior con una división o 


podremos eliminar el heightfield con la a 
orden “pop”, la cual ejerce sobre el E 
stack el efecto contrario al que produce ¿ 


la inclusión de una nueva malla. Con 
“pop”, todos los elementos de la pila a 
partir del segundo se desplazan hacia 
arriba con lo que el segundo elemento 
pasará a ocupar la cima, el tercero pa- 
sará a la segunda posición, etc. El pri- 
mer elemento es, claro está, el situado 
en la cima de la pila. 
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CÓMO... 


Ahora vamos a crear un paisaje con 
cráteres. Para ello contamos con el co- 
mando cráter cuyo formato es... 

Crater numero escala_de_profundi- 
dad escala _de_ radio distancia 

El primer parámetro indica el núme- 
ro de cráteres que van a tratarse. Los si- 
guientes se refieren a la profundidad y 
al radio de los cráteres (pero el autor de 
estas líneas confiesa que aún no com- 
prende demasiado bien el funciona- 
miento de estos parámetros. En la ayu- 
da se indica que estos valores son 
relativos a la normal ¿y?). En cuanto a 
“distancia” afecta al número total de 
cráteres que se generarán en el height- 
field. El valor por defecto para este pa- 
rámetro es 10 pero parece más conve- 


El comando Equalize. 


niente dejarlo en 5 6 4 para obtener 
más cráteres.Usaremos la sentencia, 
examinaremos el resultado final y =si 
nos parece adecuado- grabaremos 
nuestro trabajo escribiendo, por ejem- 
plo, “save crateres.tga”. Esto es todo lo 
que debemos hacer para crear un bit- 
map utilizable desde POV. 

Ahora veamos otros comandos inte- 
resantes de H£lab. 


7 


Con “Floor altura” el programa ha- 
rá que todas los vértices con alturas 
inferiores a la especificada por el pa- 
rámetro tomen la altura de dicho pa- 
rámetro. El efecto visual será el de 
crear un plano que simula el nivel del 
agua en la altura indicada por el pará- 
metro que sigue al comando. Esto 
puede sernos útil para hacernos una 
idea del aspecto que presentará el pai- 
saje desde POV, si añadimos al height- 
field un plano para simular un mar o 
un lago a esa altura. 

Otro comando del mismo estilo es 
“Ceil altura”, el cual hace lo mismo 
que el anterior pero igualando los vér- 
tices cuyas alturas exceden la indicada 
por ceil. Esto último puede sernos útil 

- para crear una planicie en 
una montaña (y colocar algo 


sobre ella, claro). 
A 


Notas del autor 

“Todas las imágenes del artí- 

culo han sido generadas des- 
de POV a partir de las tgas 

- creadas con H£-lab. 
Cada escena ha sido el resul- 
tado de un comando aplicado 
sobre el mismo heightfield 
inicial. hor cierto, tomad nota 

- de que hay que escalar el 
heightfield en Y. De lo con- 

trario la imagen que nos dará POV no 


po se parecerá a la previsualización de Hf- 


lab. Mirad el .pov. 

Tan solo hemos comentado algunas 
de las órdenes que permite Hf-lab. El 
programa tiene comandos con los que 
podremos crear picos, simular la ero- 
sión, distorsionar el bitmap de varias 
maneras, combinar dos heightfields pa- 
ra producir un tercero, etc. Así que ya 
sabéis: ¡Gforge, gforge y gforge! 
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Nora importanie. Podéis remitirnos vuestros trabajos o consultas, bien por caña a la dirección que 
figura en la segunda página de Pcnanía, o vía e-mail a rendermania.pcmaniaO hobbypress.es 


El certamen 
de Rendermanía 


Hoy, aparte del ya habitual 
carrusel de imágenes 
enviadas cada mes por los 
lectores, vamos a 
presentar una propuesta 
dirigida a todos los 
rendermaniacos. Esta 
propuesta está basada en 
el éxito que tuvo la idea, 
inicialmente concebida 
como una broma, de crear 
una batalla virtual entre 
humanos y orcos utilizando 
modelos enviados por los 
lectores. Esta propuesta 
está basada en vuestras 


propias sugerencias. 


Óscar Álvarez Díaz ya apareció en estas páginas en el número 5 con un pov- 
soldado inspirado en Star Wars, Óscar definió diversas posturas para su soldado y 
hoy ataca de nuevo con una magnífica escena donde un bunker imperial defendi- 
do por sus mejores tropas está siendo masacrado por un... ¿ataque rebelde? Podéis 
encontrar los detalles de esta obra en la carta de Óscar, en el foro. Estoy de acuer- 
do contigo en lo que afirmas sobre el manual de POV; muchas veces se echan en 
falta explicaciones adicionales de algunos comandos y estas lagunas nos obligan 
a hacer muchas pruebas adicionales. Por lo que respecta a la niebla creo que tus 
interpretaciones de los comandos para la niebla superficial son correctas, pero no 
estoy seguro de que sea posible hacer el tipo de humo que pretendías. 

En cuanto a lo que dices sobre la generación de paisajes de fondo con POV, es- 
toy parcialmente de acuerdo contigo: no es un asunto fácil (pero si factible). ¿Qué 
opinas de las dos utilidades “paisajísticas” que inclu1mos hoy en el CD? Los ár- 
boles de Sonya se crean... ¡con sentencias de POV! (apréndetelas ya). Tomo nota 
de tu sugerencia para dedicar un artículo a la generación de paisajes. Desde mi 
punto de vista el peor problema es la memoria (los arboles de Sonya o los height- 
fields ocupan lo suyo) pero incluso para esto existen soluciones que comentare- 
mos en próximos números. 
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Poco es lo que sabemos sobre esta imagen enviada por el 
grupo Epsilon, salvo que forma parte de un proyecto lla- 
mado WildRape. Este grupo solicita correspondencia so- 
bre infografía y programación y nos adjunta su dirección en 
el universo real que es: 


Epsilon 

P” Bera-Bera 57, 1% D 20009 San Sebastián Guipuzcoa 
Y su dirección e-mail en el ciberespacio: 

epsilonl Carrakis.es 


Francisco Javier Diaz Blanco nos envía una imagen 
creada con 3D Studio, programa con el cual ha tenido 
dificultades de aprendizaje. ¿Y por qué —pregunta ob- 
via— no te compraste un buen libro sobre este programa? 
Será difícil que alguien pueda explicarte en pocas pala- 
bras el funcionamiento del Keyframer ya que, si echas 
un vistazo en algún libro dedicado a 3D Studio, compro- SA 
barás que la descripción del funcionamiento de este mó- t_ 1296. AU rights resarvad 
dulo suele requerir capítulos enteros. 

En cuanto a mi opinión sobre tu imagen, te diré que 
me parece excelente teniendo en cuenta el método de 
aprendizaje que has seguido. Lo único que se te puede 
criticar, siendo muy puntillosos, es que faltan los carac- 
teres en el teclado y que la aplicación de la textura de 
madera aparece “corrida” sobre la mesa; hubieras debido 
dividir la aplicación. 


Jorge Albericio nos envía sus primeras 
pov-escenas: un templo griego y una casa ¿Y 
pides crítica y encima constructiva? Pues 

bien, en la escena de la casa lo primero que 
llama la atención son las proporciones del 
conjunto: los bancos parecen desproporciona- 
damente grandes en relación a la casa. Otro 
detalle que no convence demasiado es la tex- 
tura que has empleado para puertas y venta- 
nas. Por otro lado tu obra está muy bien para 
tratarse de una opera prima, aunque aún es 
muy pronto para saber si vas a tener futuro en 
este campo o no. Eso dependerá del tiempo y 
ganas que pienses invertir y por ello (teniendo 
también en cuenta lo que ya hay en el merca- 
do) eres tú quien debe saber mejor que nadie 
si tu futuro va a estar en esto O no. ¡Ánimo y 
adelante con las siguientes escenas! 
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Carlos Monterde Escudero es otro recién legado al mundo de 
POV que aúna la pasión por la infografía con el gusto por la pro- 
gramación. Carlos nos envía varias escenas-experimentos donde un 
objeto mágico —el Cupisferio- suele ser el punto central. Carlos bus- 
ca colaboradores interesados en realizar videojuegos (leed su carta 
en el foro) y se confiesa asombrado del nivel de realismo que per- 
mite conseguir POV, En cuanto a los problemas que mencionas, pa- 
ra conseguir sombras de bordes difusos utiliza áreas de luz. Esto 
generará sombras más reales aunque, te aviso, lo pagarás caro en 
tiempo de render. En cuanto al control de la iluminación, la senten- 
cia scale puede ser empleada para cambiar el tamaño de los objetos a los que se ha asignado una fuente de luz , lo cual no es tu caso. Pa- 
ra controlar la iluminación procura emplear pocas fuentes y limítate a cambiar el valor rgb de las mismas o su posición. De todos modos 
has logrado una atmósfera muy resultona tanto en Cupsfer. gif como en puerta.gif. 


Carlos Pastor Méndez es otro nuevo pov-adepto al que agra- 
dezco de corazón que haya decidido apoyar a mis soldaditos en 
la inminente batalla que han de librar contra los orcos. Tranqui- 
lo pov-colega, es cierto que nuestro bando tiene una ligera des- 
ventaja en cuanto a variedad de armamento pero no olvides que 
casi todo el material de los orcos se basa en catapultas mientras 
que nosotros disponemos de cañones (¡Je!). Además es posible 
que antes de la batalla se incluya alguna cosilla extra para vapu- 
lear a esos malolientes hijos de Gorko y Morko. 

En cuanto a tu carro, la idea me parece excelente aunque, no 
te ofendas, su acabado actual recuerda bastante a la manufactura 
snotling: Los misiles son demasiado grandes (y además no están 
permitidos por la convención Orco-humana) y la forma del ca- 
ñón recuerda a la de un trabuco. Por lo demás la forma general es 
bastante simpática. ¡Bienvenido a las filas humanas! 


4h Ae 
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Jorge Albericio 1997 
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Giovanni Sestini es un aficionado a la construcción de ma- 
quetas de aviones que últimamente ha decidido entrar en el 
campo del modelismo virtual. Giovanni nos envía este estupen- 
do “Macchi MC202” creado principalmente con Caligari, pro- 
grama para el que pide un mayor espacio en Rendermania (tomo nota). Giovanni también 
pregunta por algún foro de news dedicado al tema del modelismo virtual o por alguna di- 
rección de internet dedicada a este asunto. ¿Puede alguien dar algún dato sobre esto? En 
cuanto al método de construcción, Giovanni utilizó un escáner para obtener los perfiles 
del avión. Luego, estos perfiles fueron depurados con Coreldraw antes de grabar las co- 
rrespondientes plantillas Dxf que se emplearían después. Las piezas fueron montadas con 
Caligari y 3D Studio y las texturas fueron creadas con Corel Photo Paint, utilizando co- 
mo plantillas imágenes generadas con las vistas del avión. A pesar de tus notas (excesi- 
vamente rigurosas) sobre las carencias del avión. éste nos ha parecido fabuloso. 


Pablo, un programador de C++ nos remite las siguientes preguntas: 
1)¿Hay alguna tool o librería para manejar imágenes de POV desde C++? 

2) ¿Se pueden programar juegos en 3d en el lenguaje de POV? 

3) ¿Hay algún libro que explique las prestaciones del lenguaje de POV? 

Supongo que no te estás refiriendo a funciones para manejar los archivos de imagen 
generados por POV desde C++, sino a funciones para manipular el universo 3d de 
POV desde C++. Existen librerías para leer y manipular archivos gráficos de diversos 
formatos desde C++, pero no resulta posible controlar POV desde C++. El lenguaje de 
POV esun lenguaje “escénico”, esto es, se trata de un lenguaje diseñado para describir 
modelos y universos 3d. Es cierto que últimamente —desde la versión 3.0- ha empeza- 
do a desdibujarse la frontera entre el lenguaje de POV y cualquier verdadero lenguaje 
de programación. Así, POV ya admite bucles, ifs, while, rand, etc, pero sigue presen- 
tando muchas limitaciones con respecto a los lenguajes convencionales. Además POV 
emplea la técnica del trazado de rayos para representar las imágenes descritas por los 
ficheros escénicos con lo cual no resulta posible programar un juego con él ya que pue- 
des necesitar horas o días para generar cada frame. En cuanto a la documentación, pue- 
des echar mano al “Raytracing IT” de Anaya (que no trata las sentencias de “programa- 
ción” de POV puesto que sólo cubre la versión 2.0) o bien puedes leer los números O y 
1 de Rendermania. No hay por ahora otras alternativas, salvo leerse el manual. 


Muchos lectores nos han solicitado documentación sobre el formato asc de 3D 
Studio. Como de momento no pensamos tratar este tema os remitimos al Web de 
Viewpoint donde encontraréis documentación sobre éste y muchos otros formatos 3d. 
No olvidéis que este tipo de documentación suele estar escrita por usuarios que se han 
estrujado los sesos para obtener la información y no por los diseñadores de los pro- 
gramas. Por esta razón la información suele no ser fiable o completa al 100%. 
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Anuncio y propuesta 
de Rendermanía 


De ahora en adelante, y siempre que la 
respuesta que deis a esta propuesta lo per 
mita, intentaremos crear una portada cada 
cuatro meses empleando modelos enviados 
por las rendermaniacos, Esta portada estará 
dedicada a algún terna concreto que se hará 
público al comenzar cada periodo y, por sa 
puesto, los modclos que enviéis deberán 
ceñirse al tema tratado. Las escenas de 
prueba con estos modelos serán publicadas 
en el foro, donde también se seguirán pu- 
hlicando los trabajos de los lectores que no 
participen en los certámenes. 

En cada convocatoria y dependiendo 
del lema propuesto. podrán proponer Te- 
glas especiales: el uso de tal o cual uuli- 
dad, algunas limitaciones, etc. Habra, sin 
duda, algunas dificultades ya que cada 


uno deséará emplear su programa favorito . 


y habrá que realizar conversiones para trá- 
ducir cada modelo al render empleado pa- 
ra generar lá portada. ¡De vosotros depen- 
de el éxito de esta idea! La batalla entre 
orcos y humanos tendrá lugar en el núme- 
ro siguiente. Entonces anunciaremos las 
reglas para la primera portada-común y 
daremos un tema. Se admiten sugerencias: 
batallas de mechs, escenarios espaciales, 
ciudades futuristas... ¿Qué preferís? 


A 


